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INTRODUCTION 


SIAG  is  the  Norwegian  abreviation  for  the  Central  Institute 
for  Industrial  Research  (CIIR  =  SI)  and  the  Aker  Group  (AG) , 
a  cooperation  which  has  lasted  for  almost  20  years. 

SRS  is  also  a  member  of  SIAG,  acting  as  the  exclusive  marketing 
organization  at  the  same  time  as  participating  in  the  development 
projects . 

The  SIAG  cooperation  is  working  with  a  number  of  development 
projects,  of  which  the  two  major  ones  are  AUTOKON  and  AUTOFIT. 
Both  are  sizeable  projects  with  the  same  ultimate  goal,  to 
develop  CAD  systems  for  the  1980-ies.  The  projects  have  many 
things  in  common,  even  if  they  cover  two  different  engineering 
fields,  steel  and  piping.  Therefore,  this  presentation  consist 
of  four  parts: 

1.  Basic  assumptions  for  the  SIAG/CAD  developments. 

%■  Description  of  Interactive  AUTOKON 

3.  Description  of  AUTOFIT 

4.  Hardware  considerations 

of  which  the  first  and  the  last  are  common. 
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1. 


THE  SHIPYARD'S  MARKET  PLACE  HAS  CHANGED 


It  is  only  natural  that  the  needs  of  the  Aker  Group  have  been  and 
are  of  the  greatest  importance  when  it  comes  to  the  question  of 
setting  the  systems  requirements.  The  Aker  Group's  market  place 
has  changed  dramatically  over  the  last  5  years.  From  being 
Norways  biggest  shipbuilder,  accounting  for  about  half  of  the 
total  tonnage  delivered  from  Norwegian  yards,  shipbuilding  is  now 
reduced  to  less  than  20%  of  the  groups  activity  and  will  probably 
have  less  and  less  importance.  80%  of  the  activities  are  now 
concerned  with  engineering,  production  and  outfitting  of  struc¬ 
tures  for  the  North  Sea  oil  exploration.  These  changes  are  not 
significant  for  the  Aker  Group  otherwise  than  that  Aker  has  managed 
to  switch  in  time.  The  whole  shipbuilding  world  is  facing  the 
same  problems. 


1 . 1  Diversification  of  products 


In  addition  to  ships  a  number  of  other  products  have  grown  in 
importance 

o  Specialized  offshore  oilfield  exploration  and  service 
vessels,  frequently  of  the  semi  submersible  platform 
type.  Fig.  1. 

0  Offshore  oil  production  facilities,  "off  shore  cities" 
Fig.  2.  Steel  structures  of  the  typical  curved  or  flate 
panel  type  are  replaced  by  pipe-truss  structures,  f.inst. 
for  jackets. 

o  Concrete  is  substituting  steel  structures  such  as  in 
the  CONDEEP  design.  Fig.  3. 

0  These  are  just  examples.  Who  knows  what  kind  of  products 
the  present  shipbuilder  will  have  to  cope  with  in  the 
1980-ies  ? 


1 . 2  The  increased  importance  of  outfitting 


Some  of  the  offshore  products  are  a  combination  of  a  vessel  and  a 
process  plant,  a  fixed  or  floating  factory.  Typical  examples 
are  the  CONDEEP  oil  production  platform  and  the  Kvaerner's 
large  prpject  with  gas  liquidation  plant  and  storage  facilities. 
Fig.  4. 


Valhall/Hod 


The  fourth  large  project 
on  the  Norwegian  Continental 
Shelf. 


Floating  gas  liquidation  plant  and  storage  tanks. 
Behind  the  plant  a  gas  carrier  is  loading 


Fig .  4 
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Outfitting  problems  are  increased  by  a  factor  5-10  compared  with 
convectional  shipbuilding.  Pi-ping  systems,  in  particular,  are  of 
considerable  size  and  complexity.  The  demand  for  efficient 
computer  tools  to  handle  piping  engineering  is  therefore  imminent. 


1 .3  The  products  are  very  complex  prototypes 


Little  is  left  of  the  nice  period  of  repetitive  production  of 
long  series  of  ships .  Not  only  are  the  product  more  complex  in 
design,  they  are  prototypes  to  a  very  large  degree.  There  is  less 
previous  experience  to  build  on.  The  frequency  of  design  changes 
is  very  high.  Both  design  and  production  engineering  represent  a 
tremendous  task  of  coordination.  Most  problems  occured  are  due 
to  lack  of  proper  product  documentation  which  is  either  incorrect, 
inconsistent  or  missing. 


1 , 4  Explosion  in  demand  for  documentation 


Break  downs  in  operation  of  the  offshore  structures  may  have 
enormous  economical  and  environmental  consequences.  Extensive 
non  destructive  testing  is  required  and  puts  heavy  demands  on 
administration  of  the  quality  control  procedures  and  in 
particular  on  the  documentation  of  results.  Missing  material 
certificates  or  inadequate  reference  of  X-rays  films  to  actual 
pieces  of  pipes  or  steel  plates  may  cause  costly  replacements 
during  production.  This  information  is  closely  tied  up  with  pro¬ 
duct  itself . 

Further  the  clients  demand  all  kind — of  reports  as  regarding  the 
status  of  engineering  and  production.  This  was  something  quite 
different  from  the  experience  with  shipowners,  who  normally  did 
not  care  about  the,  builders  procedures  and  methods,  as  long  as 
the  ship  was  delivered  in  time  and  according  to  specifications. 


1.  5  Lead  time  is  short 


Considering  the  fact  that  the  products  are  complex  prototypes,  the 
lead  time  is  much  shorter  than  was  the  case  with  most  ships. 


87 


Very  heavy  demands  are  put  on  "engineering"  projects,  detailed  design 
documentation  for  prefabrication,  shop  assembly  and  field  assembly. 
And  not  to  forget  materials  supply! 

Short  lead  time  must  be  expected  to  be  the  rule  rather  than  the 
exception  in  the  future. 


1 ,  6  Product  in  focus 


The  shipbuilder  is  used  to  a  kind  of  function  oriented  management, 
like  a  "production  line"  where  similar  engineering  tasks  on  all 
products  are  "passing"  the  various  engineering  departments. 

A  much  more  product  or  project  oriented  management  is  demanded. 

In  other  words,  the  products  is  in  the  focus  and  all  functions, 
either  technical  or  administrative  have  to  organize  themselves, 
around  the  product. 

The  produtcts  itself  is  the-source  of  all  essential  and  necessary 
information  for  all  functions  supporting  engineering  and  production. 


1.7  More  subcontracting 

Due  to  the  size  and  complexity  of  the  projects  we  have  seen 
examples  where  both  engineering  profabrication  and  assembly 
work  have  been  farmed  out  to  a  number  of  companies  spread  all 
over  the  continent.  It  is  evident  that  this  puts  some  heavy 
demands  for  coordination  on  the  main  contractor. 

What  would  be  the  main  source  of  information  to  be  able  to  control 
it  ?  First  of  all,  proper  products  documentation. 


These  facts  of  life  have  some  important  bearing  on  what  kind  of 
computer  aids  we  should  look  for,  and  they  put  some  pretty  heavy 
demands  on  systems  development. 
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2. 


DEMANDS  ON  SYSTEMS  DESIGN  AND  IMPLEMENTATION 


If  we  look  back  on  the  AUTOKON  development,  the  very  fact  that 
triggered  it  off,  was  the  desire  to  feed  a  piece  of  work  shop 
eguipment  with  N/C  burning  tapes  as  efficiently  as  possible, 

The  systems  designed  for  the  1980-ies  must  incorporate  quite 
substantially  more  and  be  radically  more  efficient  than  systems 
available  in  1978. 


2 . 1  High  degree  of  products  independence 


This  demand  on  systems  design  should  be  obvious  from  the  previous 
section.  Interactive  AUTOKON  will  not  be  associated  with  stiffened 
"steel"  panels  only,  but  be  equally  applicable  to  any  type  of 
geometry  and  materials.  AUTOFIT  will  be  independent  of  purpose 
of  piping  systems:  ship  system,  process  plant  systems  for  petro¬ 
chemical  or  chemical  purposes.  In  AUTOFIT  the  goal  is  even  higher, 
since  the  concept  is  basically  general  for  analogueous  out¬ 
fitting  problems:  piping,  ducting,  electrical. 


2.2  Source  for  generation  of  product  documentation 


By  tradition  any  product  is  implicitly  described  by  its  drawings. 
The  drawings,  tables  and  other  documents  represent  the  "database". 

The  same  product  (f.inst.  a  ship)  may  be  documented  in- just  as  many 
different  ways  as  the  number  of  yards  building  it,  according  to 

local  needs  and  practices.  And  the  same  ship  can  be  split  into 
quite  different  prefabrication  arid  assembly  units  depending  on 
local  practice  and  facilities . 

The  nucleous  of  the  system  is  therefore  the  computer  based 
product  model  which  represent  the  product  "reality".  The  product 
documentation  is  basically  reflections  of  this  model  in  terms  of 
composed  layouts,  presentation  of  different  views,  merging  of 
drawings  and  tables  etc.,  in  other  words,  manipulated  information 
with  its  origin  in  the  product  model. 
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2.3 


Serve  as  document  files  (archives) 


The  computer  based  document  file  shall  be  the  "original".  When 
the  product  model  is  modified  the  database  "original"  will  be 
automatically  updated,  or  at  least  the  system  shall  advise  on  the 
consequences  of  the  modifications.  On  the  other  hand,  drawings 
may  contain  a  variety  of  information  which  do  not  directly  affect 
the  product  model  itself.  The  advantage  of  having  the  "original" 
in  the  system  rather  than  as  a  transparent  paper  in  a  cabinet 
drawer,  is  obvious.  Technologically  one  is  very  close  to  sol¬ 
ving  the  problem  of  using  ordinary  TV-screens  to  vizualize  data 
bank  contents,  which  may  have  a  dramatic  effect  on  distribution 
of  documentation. 


2 . 4  Serve  as  source  of  information  in  general 


To  be  mentioned 

o  Analysis  and  calculations 

o  Other  design  and  production  engineering  functions 

o  Materials  supply 

o  Methods  and  planning 

o  Quality  control 

o  Cost  control 

0  Shop  automation 

In  fact,  the  product  model  and  document  file  comprise  the  very 
source  of  almost  all  information  needed  by  any  other  function  in 
engineering  and  manufacturing  of  the  product. 

In  comparison  with  most  technical  systems  of  to-day,  the  potential 
"harvesting"  effects  are  tremendous.  The  information  system 
aspects  are  just  as  important  as  the  "computer  aided  design" 
itself. 


2 . 5  Excellent  user  communications  are  required 


The  above  mentioned  items  are  concerned  with  the  properties  of  the 
information  system  as  such.  However,  with  to-days  batch  technology 
we  would  be  very  badly  off  when  communicating  with  it.  Therefore, 
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on-line  interaction  is  a  necessity  to  provide  proper  communi¬ 
cation  between  the  user  and  the  system.  It  concerns  both  inter¬ 
active  graphics  and  on-line  selective  information  retrieval  on 
alpha  numeric  terminals. 

Frequenlty,  we  see  interactive  graphics  evaluated  more  as  a 
goal  in  itself,  rather  than  as  a  means  of  communication  with  an 
information  system. 


2 , 6  High  degree  of  hardware  independence 


In  our  development  we  are  aiming-at  separating  what  to  do  from 
how  to  do  it.  The  first  aspect  of  the  information  system  is 
rather  statical  over  time,  while  the  other  is  dependent  on  the 
current  computer  technology  available.  A  major  objective  is 
therefore  to  create  an  information  system  which  comply  with  the 
needs  of  the  user  without  forcing  him  into  complete-hardware 
dependency . 

Software  portability  should  be  considered  important  by  any  user, 
because  he  will  have  to  face  the  rapidly  changing  developments 
in  computer  technology.  For  us  and  from  the  point  of  view  of 
marketing  portability  is  crucial.  We  are  convinced  that  the 
wide  distribution  of  AUTOKON  is  partly  to  be  credited  to  the 
fact  that  the  system  was  reasonably  portable,  portability  is 
not  granted  free  of  charge,  it  must  be  deliberately  built  into 
the  system  during  development. 


2 .  7  Standardization  of  software  components 


In  order  to  obtain  the  desired  implementation  independency  the 
systems  are  made  self contained  with  regard  to  such  facilities 

as  database  software,  picture  file  system,  command  processor, 
segmentation  system,  general  picture  graphics,  system,  etc. 

Most  of  these  software  components  are  of  general-purpose  nature. 
Apart  from  serving  above  needs,  they  also  facilitates  standardi¬ 
zation,  which  again  means  lower  system  development  costs  and 
system  maintenance  costs. 
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3. 


THE  INTEGRATED  PRODUCT  MODEL 


One  of  the  ways  to  meet  the  various  demands  imposed' on  the  system 
is  the  introduction  of  the  product  model.  Since  so  much  em- 
phssis  is  given  to  the  product  model,  this  section  will  be 
devoted  to  an  elaboration  of  this  concept. 


3 . 1  The  problem  to  be  described 


What  is  to  be  described  in  the  model  ?  The  products  which  are 
considered  here  can  be  viewed  in  many  ways.  If  interested  only 
in  the  funciional  purpose  of  the  product  as  a  whole,  certain 
performance  parameters  may  be  sufficient. 

If  interested  in  structural  detail,  it  may  be  necessary  to  have 
an  exact  description  of  shape  and  position  of  the  detail.  Due  to 
the  enormous  amount  of  detailed  structure  which  may  be  present  in 
the  considered  products,  the  representation  in  the  database  is 
essential  for  a  successful  system. 

Also  the  functional  relationships  in  the  detailed  structure  and 
the  way  such  details  are  put  together  to  form  larger  logical  units 
is  essential  and  must  be  reflected  by  the  logical  description  in 
a  simple  and  efficient  manner. 

To  the  model  which  thus  emerges  must  be  added  various  user  functions 
like  the  output  of  reports/drawigs,  generation  of  meshes  for 
finite  element  analysis,  etc.  Also  to  be  considered  is  the  efficient 
handling  of  numerous  updates  and  changes  which  is  so  typical  to  the 
process . 


3 . 2  Some  functional  requirements 


0  It  must  be  possible  to  communicate  with  the  model  inter¬ 
actively  by  means  of  information  in  drawings,  text  and  tables. 

0  The  data  must  be  available  for  new  and  possibly  unforeseen 
applications.  The  data  must  be  stored  and  structured  in  a 
tidy  and  "modular"  manner  which  allows  restructuring. 
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o  Description  of  the  model  must  be  possible  even  though  exact 
or  final  parameters  are  not  available.  The  same  model  must 
still  be  valid  when  final  parameters  shape  has  been 
determined. 

0  The  consequences  of  updatings  must  either  be  considered 

automatically  or  the  user  must  be  told  where  and  what  to 
update . 

o  Redundant  data  should  be  avoided  as  much  as  passible. 

A  consequence  of  this  (which  has  more  meaning)  is  that  if 
we  feature  is  to  he  changed  this  should  mean  only  one 
logical  update  in  the  database  even  if  consequences  are 
numerous . 


3 . 3  The  integrated  product  model 


The  purpose  of  a  CAD/CAM  system  is  to  solve  one  or  more  design  or 
manufacturing  problems.  Consequently  the  total  data  base  model  must 
primarily  reflect  the  requirements  of  all  the  relevant  applications. 
However,  existing  applications  change  and  new  ones  are  added.  This 
implies  a  need  for  a  central  description  reflecting  the  product  in 
a  general  way  rather  than  any  applications.  This  central  product 
model  is  the  common  denominator  to  all  applications?  Ideally  it  is 
not  effected  by  changes  or  additions  in  these. 

Applications  do  exist,  however,  and  must  be  appropriately  integrated 
in  the  system.  The  different  applications  in  a  total  system  may 
communicate  with  the  product  model  in  a  number  of  ways  (fig.  5)  . 


1.  The  application  works  on  a  common  data  description  (central 
product  model)  .  This  model  contains  all  the  relationships  and 
other  information  needed. 

2.  The  application  derives  its  data  from  the  model.  The  derivation 
may  be  performed  through  procedures  (programs)  which  produces 
new  data.  If  the  procedure  is  considered  a  part  of  the  model, 
then  the  model  is  said  to  be  procedure  oriented. 
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DATA  BASK  MCJDKD 


Fig.  5  How  various  applications  may  communicate 
with  the  product  model . 
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3.  Interface  programs  transform  all  relevant  information  to  a 
suitable  form  which  is  used  by  the  application.  This  solution 
results  in  several  representations  of  the  same  data  and  hence 
consistency  problems.  It  may,  however,  result  in  simpler  data 
structures . 

4.  Data  are  derived  manually  from  drawings,  tables  etc. 

The  product  oriented  model  is  the  most  static  element  in  the 
overall  database  model. 


3.4  The  product  model  is  change  oriented 


A  common  way  of  describing  geometry  in  interactive  graphics  is 
by  a  number  of  closed  or  open  planar  polygons  where  each  side 
of  the  polygon  is  described  by  referring  to  the  endpoints.  If 
any  such  point  is  displaced  then  all  polygons  involving  that 
point  will  be  changed  as  well.  We  wish  to  generalize  this  effect 
by  using  logical  references  for  curves  and  surfaces  as  well  as 
for  points.  The  effects  we  wish  to  obtain  is  perhaps  best  illu¬ 
strated  by  the  following. 


Fig.  6 


In  fig.  6  we  have  for  example  started  off  with  a  description  of 
the  shape  of  a  ship  hull.  This  hull  may  be  defined  in  a  variety 
of  ways,  but  for  the  same  of  argument  the  representation  may  be  a 
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set  of  transverse  frames  (T)  .  The  important  point  is  that  the 
longitudinal  frame  @  and  the  -flange  of  the  web  frame  (3)  is 
defined  relative- to -the  hull- description .  This  means-that  pri¬ 
marily  the-data  base  contains -a ^description  of -how  (gj  and  (5)  is 
derived  frqm  the  hull**  description  (l)  for  example,  by  a  reference 
to  a  parallel  routine  and  the  relevpit  parameters  (parallel 
distance).  Furthermore  the  bracket  W  is  again  defined  relative 
to  (2)  .and  (i)'>  Ndte  'that;  even. if  the  geometry  has  not  yet  been 
described,  the  other  features  may. 

The  purpose  of  the  product  model  is  to  describe  the  product  .  by 
identifying  its  functional  entities  and  their  relationships  or 
"connection  structures".  These  connection  structures  we  refer  to 
as  the  topology  of  the  product.  The  topological  description  is 
separated  from,  but  may  refer  to,  the  geometrical  descriptions. 

In  cases  of  geometrical  changes -the  topological  description  refers 
to  sufficient  information  to  generate  the  new  geometrical  solution. 


This  approach  has  the  following  advantages: 

Only's  minimum  of  geomentrical  data  is  needed  to  describe 
the  structure  (minimum  of  data  redundancy)  .  Thus  it  means 
less  work  in  the  initial  definition  of  the  product. 


The  descriptions  of  topology  and  geometry  are  separate 
and  independent  of  each  other  which  means  that  for  a  ship 
the  internal  structure  may  be  defined  prior  to  having 
defined  the  hull  shape.  More  generally  this  allows  flex¬ 


ibility  as  cor 
design  process 


cerns  the  work  sequence  in  a  typical  engineering 


(fig.  7)  . 


Fig..  J:-  Reduction  in-  lead  time. 
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All  the  geometric  consequences  of  a  change  in  scantling 
(the  most  typical  change)  will  inherently  be  taken  care  of 
without  additional  changes  to  the  data  base.  The  ability 
to  handle  changes  and  updates  is  certainly  a  major  problem 
area.  The  topological  description  should  reduce  this  problem 
to  a  minimum  giving  a  change  oriented  system. 

Additional  or  alternative  geometric  representations  are 
easily  introduced.  This  is  due  to  the  fact  that  the  major 
part  of  the  product  description  is  geometry  independent  and 
therefore  does  not  change. 


3 . 5  General  layout  of  the  database 


At  the  top-level  of  database  design,  the 
as  consisting  of  two  parts  [see  fig.  8) 


system  may  be  considered 


1.  Integrated  product  model: 


This  part  constitutes  the  internal  model  of  the  object 
(product,  drilling  rig,  ship,  production  platform,  jacket 
etc.  or  only  part  of  these)  .  Note  how  the  "topological  des¬ 
cription"  (TOPOLOGICAL  UNITS)  are  separated  from  the  para¬ 
metric  descriptions  (SURFACE-,  POINT-,  CONTOUR  UNITS)  the 
former  only  referring  to  the  latter. 

2.  Communications: ' 


This  part  takes  care  of  the  communication  with  the  central 
database  and  also  contains  the  archives  of  the  reports/ 
documents  which  have  been  made. 
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INTEGRATED  PRODUCT  MODEL 


Fig.  8  THE  COMMUNICATION  DATA  STRUCTURE 
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FRESENT  AUTOKON  APPLICATION  IN  BATCH  TECHNOLOGY 

,/ 


It  is  considered  appropriate  to  give  a  summary  on  the  present 
AUTOKON  before  elaborating  on  the  new  developments. 


The  existing  AUUTOKON  applications  in  batch-technology  is  based 


on  the  use  of  a  set  cf  FORTRAN  programs  labellec 
a  library  of  ALKON  systems  Norms. 


See  fig.  1 


AUT0K0N-7  6  with 


Fig.  1  AUTOKON  information  system 
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The  "shell  structure"  modules  of  autokon-7  6  have  proved  to  be 
equally  usefull  as  design"  and  lofting  tools.  Actually,  these 
tools  do  the  same  job,  whether  early  or  late  in  the  process. 

The  benefit  to  the  designer  is  a  matter  of  his  attitude  and  willing¬ 
ness  to  use  it  in  his  work. 


As  concerns  "internal  structure",  ALKON  and  the  Systems  Norms 
library  may  perform  lofting  in  an  efficiently  way.  However, 
extended  use  of  ALKON  in  design  and  production  preparation  re¬ 
quired  an  enhanced  norms  library. 

A  special  norms  library  for  extended  use  on  $hips  was  developed 
in  the  Aker  Group.  This  design  and  production  norms  library 
comprises  "packages"  for  a  number  of  purposes: 

o  Norms  to  establish  data  structures.  These  are  general  and 

we  do  believe  in  particular  that  the  production  phase  data 
structure  is  a  convention  which  may  be  used  by  all  ALKON 
users.  This  structure  provides  the  possibility  to  extract 
a  number  of  information  by  drawing  norms  and  list  norms. 

I 

0  Norms  to  describe  surface  and  surface  structures  (plates 

and  stiffening) .  These  packages  are  mostly  "function" 
and  "geographically"  oriented:  Double  bottom,  web  frames 
in  engine  room,  etc.  They  have  been  run  on  several  ship 
projects  and  have  been  modified  for  increased  generality. 

o  Norms  to  describe  types  of  codes  (f.inst.  material  identi¬ 

fication  for  plates  and  profiles)  and  various  standards. 

o  Drawing  norms  for  design  and  production  drawings,  either 

ordinary  block  drawings  or  levels  .of  drawings  reflecting 
the  assembly  structure. 

o  List  norms  for  generating  various  types  of  tabular  informa¬ 

tion,  stiffener  lists,  assembly  lists,  weight  and  center 
of  gravity  of  blocks  and  sub-assemblies,  etc. 

The  above  norm  packages  mdke,'of  course,  frequent  use  of  the  basic 
"System  Norms"  in  possession  of  all  ALKON  users. 


The  integrated  design  and  production  norm  makes  it  justified-to 
classify  AUTOKON-76  an  "information  system",  .even  if  the  batch 
technology  leaves  a  lot  to  be  desired  as  regards  communication  with 
the  database. 


Fig.  2  ((fives  a  schematic  outline  of  the  various  norm  packages  and 


their  place  in  the  downstream  process. 
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5  " 

It  must  be  admitted  that  these  enchanced  norms  libraries  did 
not  create  a  break  through  of  ALKON  in  design. 

First  of  all,  the  batch  technology  is  not  very  suitable  for 
convincing  the  designer  that  the  computer  can  beat  him  in 
making  a  drawing.  Since  he  has  to. face  changes,  the  computer 
would  rather  delay  him  than  speed'  up  his  work.  He  is  not  willing 
to  accept  that  even  if  somebody  down  stream  obviously  would  bene¬ 
fit  bv  reduced  work  load  and  higher  accuracy. 

'  However,  notwithstanding  batch  deficiencies,  a  great  deal  of 
the  short  comings  came  from  the  way  ALKON  was  used,  and  not  from 
basic  limitation  in  ALKON  itself,  since  it  is  probably  one  of  the 
most  powerfull  geometry  compilers  available. 

o  It  was  not  fully  apprehended  that  a  very  thorough  system 

analysis  of  the  "design  process,  "formalized  procedures  and 
extensive  standardization  work  were  fundamental  prior  to 
coding  an  "hierarchy  of  ALKON  norms  to  cope  with  design: 

o  It  was  not  fully  understood  that  norms  development  of  this 

magnitude  was  genuine  systems  development,  and  that  the 
basic  reguirements  as  to  user  specifications,  systems  design, 
systems  programming  and  documentation  were  valid.  No  matter 
whether  the  programming  language, was  ALKON. 

@  The  efforts  involved  and  demands  on  gualif ications  of  parti¬ 

cipants  were  underestimated. 

r  •  r 

0  Lack  of  time  for  creating,  sufficient  "generality"  because 

of  pressure  from  production  schedules. 

o  When  the  norms  were  ready,  the  majority  of  Aker  Group 

ship  contracts  were  cancelled  and  efforts  turned  towards 
offshore  structures. 


In  spite  of  above  experience, .  the  norms  library  has  proved  useful 
for  the  Aker  Group.  both"for  ships  and"  semi-submersibles . 


The  power  and  felxibility  , of. ALKON  has  really  been  proved  in 
connection  with'  unusual;, constructions  such  as  pipe-trusses  (jackets) . 


At  the  Aker  Verdal  yard  they  managed  to  increase  work  preparation 
efficiency  considerably  by  creating  a  special  norms  library  for 
jacket  design,  |fiq.  37 
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After  a  few  weeks  the  first  norm  were  actually  used  in  produc¬ 
tion  preparation.  The  norm  which  generates  the  template  for 
the  cutting  of  truss  connections  (activity  8)  produces  a  template 
in  20  -  30  minutes.  Manually  a  good  craftsman"  would  manage  2  to 
3  templates  a  day. 

The  accuracy  obtained  using  a  numerical  method  was  far  better  and 

a  substantial  saving  and  better  product  quality  was  registered. 

Let  us  just  mention  that  in  12  leg  Jacket  which  has  been  built 

there  were  560  such  templates.  The  tubes  in  the  Jacket  had  a 

diameter  of  up  to  1.5  meters  and  a  plate  thickness  of  up  to  70 

millimeters.  The  actual  truss-connections  may  be  very  complex 

often  with  tubes  intersecting  eccentrically. 

\\ 


2.  INTERFACING  THE  PRESENT  AND  FUTURE  AUTOKON 


3  years  ago  it  was  decided  to  develop  a  new  AUTOKON  system  for 
the  1980-ies.  Based  on  the  requirements  previously  set  forth 
and  the  knowledge  of  short  comings  .of  present  AUTOKON,  it  is 
obvious  that  Interactive  AUTOKON  had  to  be  established  on  an 
entirely  new  concept. 

The  development  project  started  with  AUTONEST,  the  new  operatio¬ 
nal  interactive  nesting  system,  and  has  another  3-4  years  to 
go.  However,  since  short  term  results  was  demanded,  the  goal  is 
to  provide  the  user  with  the  best  total  system  throughout  the 
development  period  until  the  present  AUTOKON  is  finally  replaced 

Hence,  it  is  not  the  intention  to  throw  the  present  AUTOKON 
overboard.  On  the  contrary  it  represents  a  powerfull  and  flexible 
tool  that  has  reached  a  remarkably  high  operational  reliability. 

Our  development  policy  is  to  get  short  term  results  which  can 
extend  the  present.  AUTOKON  usage  at  the  same  time  as  being  inte¬ 
grated  parts  of  the  new  system. 

We  believe  this  development  policy  is  to  the . advantage  of  all 
present  AUTOKON-76  users,  since  it  will  allow  them  to  change 
gradually  towards  the  full  Interactive  AUTOKON  if  desired. 
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3.  INTERACTIVE  AUTQKON v(  IA ), - ^  r  .  -  *  -- 

'«•«!«  VJ.  *  /  '  ,  "  i‘ 

Fig.  I»  is  a  description  of  iA  in  terms  of  functions  and/or. 
applications  to  be  covered.  The  figure  reflects  the  demands 
on- modern  technical,- information  system  previously  mentioned 
.  and  demonstrates  the  central-  position  of  the  product  jnodel  as 
a  source-  of  information.  ■  In. fact,  the  figure  is  valid  for  all 
technical  information  systems  covering  different  engineering 
-fields  (steel,  piping.,  electrical, .  .etc .  )  . 

It  maybe  of  interest. to  . compare, these .  functions  with  the, modules 
of  autokon-76.  It  should  be  kept  in  mind  that  all  functions  are 
based  on  use  of  interactive  graphics,  hence  this  is  not  partice- 
larly  mentioned  under  each  item. 


Product  model  building. ' 

This  function  is  perhaps  the  most  vital  since  it.  is  the  beginning 
of  the  process.  Model  building  incorporates  separate  topological 
and  geometrical  description  as  well  'as  data  on  -functional  reguire- 
ments,  material  properties, ete .  The  product  model  includes  both 
a  design  oriente'd.  (functional' ) :  'structure  and  a  production  -oriented 
structure.  :A-particular .part  belongs  to  deck  A  at. the.  same  time 
being  included  in  subassembly  B. 

Compared,  .to. AUTOKON-76  .this  function  includes  FAIR,  LANSKI,  SHELL, 
ALKON  and  in  partiicular  the  enhanced  norms  Library.  "  . 
i  c  . '  ;  (  v 

a  .  '  *  .  >  . 

Product  documentation' 


This  f  unction  offer  powerfull  facilities  for  verification, .and 
manipulation  bf  product  in  informationin  terms  of  drawings,  tables, 
etc..  It  means  a  significant  diference  from  the  batch  tehnology, 
which  is  rather  inflexible  as  regards  composition,  presentations 
etc.:other  .than. -'programmed" .  .It  represents .the  "draftsman"  and 
is  really  a  ref lection . of  the  fact  that-' 'there  are  many  ways  to 
visualize  and  verify  a  Product.. kr  .  - 

In  AUTOKON- . 76" . tihe  drawing/printing  functions,  are  found  inherence 
in  all  program  modules.;  and:  in  the  enchanGed  norms,  library. 


In  IA  this  functidn  is  more  a  "general  drafting  tool"  which  also 
have  the  responsibility  to  administrate  the  document  file. 
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SYSTEMS 


3.3  Break  down  of  production  manufacturing  elements 

Starting  from  the  design  product  model,  this  process  will  be 
more  or  less  automatic.  The  efforts  cbnsumed  will  be  drastically 
reduced  compared  with  traditional  "part  coding"  which  will  almist 
disappear . 

Based  on  this  production  oriented  product  model,  generation  and 
manipulation  of  work  shop  documentation  will  be  made  in  the  same 
way  and  by  the  same  tools  as  in  3.2. 

Comparing  with  AUTOKON-76;  this  function  incorporate  features 
found  in  the  programs  LANSKI,  OSHELL,  L FRAME ,  TEMPLATE,  JIG,  ALKON 
and. NEST. 

3.4  Product/guality  control  functions 

Such  facilities  are  non-existent  in  present  AUTOKON-76. 

The  new  functions  are  generally  concerned  with  providing  special 
drawings  convenient  for  control  and  for  establishing  "as  built'" 
information!  The  second  major  objective  is  to  tie-up  all  kind 
of  testing  and  certificate  data' to  the  product  model  and  admin — 
strate  the  cohtrol  documentation. 


3.5”  Generation  of  control  info  for  , shop  automation 

This  function  is"the,  link  to  CAM.  Since  the  product  model  contains 
all  information  regarding  both  finished  parts  and  finished  product, 
it  is  a  matter  of  post  processing  such  data  to  control  information. 

More  important  is  the  fact  that  the  product  model  contains  informa¬ 
tion  to  control  robots  f.inst.  welding  robots.  The  potential  exists 
for  sibilating  welding  procedures. 

In  this  respect  IA  opens  up  for  a  wide  range  of  CAM  applications, 
compared  to  AUTOKON-7  6,  which  is  limited  to  N/C  data  in  SHELL  and 
NEST  . 
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3.6 


Material  demands 


autokon-76  offers  little  in  this  respect,  especially  in  early 
stage  for  material  ordering  unless  the  enhanced  norm  library  is 
used.  In  this  respect  IA  will  mean  a  great'  step  forward.  This 
function  will  maintain  a  full  1:1  correspondance  between  enginee¬ 
ring  and  material  status,  'keeping  track  of  conseguences  of 
design  changes  on  materials'  specif ication  vice  versa.  A 
variety  of  material  summaries  will  be  available  and  the  material 
demand, file  is  the  source  of  information  for  the  material  admini¬ 
stration  system.  ' 

1  •  ii  • 


3.7.T  Relating  ixobluct  units  to  manufacturing 

This  function  will  provide  facilities  for  calculations  for  proces¬ 
sing  times  (cutting;  welding  etc.)  and  for  relating  parts  and 
assemblies  to  shop  equipment  and  production  flow  to  ease  production 
planning  and  control..  Of  even  more  potential  value  is  the  possibi¬ 
lity  of  interactive  simulation  to  investigate  production  'methods. 


3 . 8  Interface  to  calculation  and  analyses  p  r  o  g  r  a  m  s 

Typical  examples  are  hydrostatics"  hydrodynamics,  structural  analyses. 
These  programs  may  either  be  inteegrated  directly  with  the  product 
model  (f.inst.'  hydrostatics)  or  work  on  derived  (simplified)  design 
models, such  as,  in  the  case  of  generating  meshes  for  finite  elements 
calculations. 


3 . 9  Communication  with  other  technical  systems 

The  most  typical  example  is  the  need  for  structural  information 
as  "background"  when  doing  piping  layout.  Or  vice  versa,  the  piping 
information  system  will,  provide  exact  position  of  all  pipe  penetra¬ 
tions  in  structures. 

The  outline  of  functions  31.  -  3.9  above  is  equally  valid  for 
other  technical  information-  systems.. 
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4. 


BRIEF  DESCRIPTION  OF  INTERACTIVE  AUTOKON  "MODULES" 


4 . 1  General  on  terminology" 

In  AUTOKON-. 76  a  module  is  a  program,  performing  a  well  defined 
task.  Tne  module  structure  is  rather  rigid  and  is  self  contained 
with  output  routines 

In  the  previous  section  the  1A  functions  were  briefly  described. 

A  function  may  contain  a  number  of  applications  or  procedures 
which  make  up  the  totality  of  jobs  or  tasks  either  from  an  organi¬ 
zational  point  of  view  or  because  it  is  a  convenient  and  natural 
way  to  group  tasks . 

Example:  Material  take-off"  and  making  bill  of  materials  for  steel 

plates  and  bars . 

A  certain  procedure  may  be  required  and  incorporated  in  different 
responsibilities  at  different  points  of  time. 

F.inst.,  the  interactive  nesting  system  AUTONEST  cotains  3  clearly 
distinguishible  and  (from  a  systems  point  of  view)  separate  phases: 
preparation,  lay-out  (nesting)  and  cut/mark  sequencing.  Together 
these, 3  procedures  cover  the  total  task  to  complete  nesting  as  a 
loft  function  with  the  ultimate'  goal  to  generate  a  N/C  tape. 

On  the  other  hand,  the  lay-out  (nesting)  procedure  should  be  avail¬ 
able  to  the  material  take-off'  man  who  is  working  several  months 
earlier  than  the  loftsman.  In  other  words,  the  same  procedure  may 
appear  in  different  functions .  A  procedure  may  be  small  or  large 
in  terms  of  EDP  programs.  The  basic  level  is  an  action  routine 
governed  by  commands. 

An  efficient  command  processor  is  avaiiable  to  link, together  action 
routines  to  higher  level  procedures,  procedures  organized  into  tasks 
and  tasks  organized  into  functions. 

From  a  systems  point  of  view,  therefore,  IA  must  be  regarded  as  a 
tool  kit,  a  big  library  of  basic  tools  (action  routines)  which  may 
be  organized  as  described  above. 

The  "user  manual"  as we  know  it,  will  be  reflecting  how  to  Perform 
a  task  by  means  of  a  particular  collection  of  action  routines .  The 
command  processor  allows  the  user  to  switch  quickly  from  one  proce¬ 
dure  to  another,  even  if  he  may  see  each  procedure  as  "fixed" . 
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Therefore,  a  module  does  not  have  the  same  meaning  in  IA  as  in 
AUTOKON-76  .  However,  certain  names  have  been  selected  to 
express  functions  as  a  total  or  to  signify  procedures  or  appli¬ 
cations  as  part  of  functions.  These  names  may  change,  so  may  also 
the  "contents"  relative  to  the  name. 

Due  to  the  relatively  long  term  period  of  the  IA  development,  the 
specifications  are  not  of  equal  degree  of  detail,  depending  on 
the  priority  given  to  them. 


Names  of  functions  and  applications 

Fig.  5  is  the .previous . fig .  4  supplied  with  names  presently 

given  to,  either  functions  or.  procedures/applications  in  IA. 

The  main  functions  are  covered  by 


AUTOMODL 


AUTODRAW 


AUTOCONT 


Design  and  production  oriented  model  building 
including  break  down  of  product  structure  for 
prefabrication  and  assembly  purpose. 

General  drafting  tool  for  visualization  of  product 
model  and  for  generation  of  design  and  production 
documentation, 

Serving  product /quality  control  functions 


AUTOPROD  Providing  link  between  CAD  and  CAM.  Generation 

control  information  for  shop, automation . 

AUTOPLAN  Relating  product  units  to  manufacturing  lines 

and  processes. 


AUTOSPEC 


Serving  the  material  take-off  function 


Within  the  functions  fig.  5 


ihows  the  following  procedures  or 


applications  ,  with  a  circumscribed  name: 


AUTOPART 


The  "bottom  level"  of  AUTOMODL,  providing  a  subset 
for  interactively  generating  parts  or  dividing  or 
modifying  ALKON  parts  from  AUTOKON — 76. 


AUTONEST 


Interactive  parts 
nested  sheets. 


nesting  generating  N/C  tapes  for 


AUTODRAW (S)  Subset  of  AUTODRAW  intended  for  generation  and 

manipulation  of  shopdrawings  with  a  short  term 
goal  to  use  autokon-76  data. 


Fig.  5.  Interactive  AUTOKON;  names  of  functions  and  applications 


AUTOMATO 


Subset  of  AUTODRAW  to  generate  and  edit  various 
kinds  of  shop  drawings  for  collar  plates,  marking 
of  stiffeners,  stiffener  lists,  etc.  To  some 
extent  AUTOMATO  will  serve  material  take  off 
function  also. 

AUTOCONT (S)  Subset  with  the  limited  objective  of  providing 

special  control  drawings  for  follow-up  during 
construction . 


AUTOPART,  AUTONEST,  AUTODRAW(S),  AUTOMATO  and  AUTOCONT (S),  represent 
the  short  term  results  of  the  IA  developments. 


By  communication  with  the  AUTOKON-76  database,  they  provide  effficient 
interactive  tools  to  manipulate  A-7  6  data  in  a  way  that  cannot  be 
done  within  A-76  itself.  This  connection  is  indicated  in  fig.  6. 

They  assume  all  "shell  modules"  of  A-76  to  be  used.,  Further,  the 
more  extensively  ALKON  and  norms  libraries  are  used  to  build  up  the 
structure  (the  A-76  product  model),  the  more  information  is  available 
for  further  manipulation  by  the  interactive  procedures. 


At  the  same  time,  as  already  pointed  out,  the  same  procedures  are 
subsets  of  the  final  IA  system,  which  should  be  seen  from  fig.  7. 


In  this  way,  the  development  policy  expressed  in  section  3  is 
implemented  by  offering  the  AUTOKON  user  the  best  total  system 
throughout  the  development  period.  These  short  term  "results  effi¬ 
ciently  attack  the  product-ion  preparation  area,  which  account  for 
some  50%  of  the  engineering  hours  in  handling  of  steel  structures. 


In  addition  to  above  mentioned  procedures, 
2  interface  programs  to  analysis,  programs. 


fig.  5 


do  also  include 


AUTOPREL  :  Making  the  IA  product  model  available  for  a  net 

PRELIKON  system,  planned  to  be  developed  in 
cooperation  between  SIAG  and  the  other  Norwegian 
parties  . 

AUTOFEMI  :  Generating  a  derived  design  model  for  providing 

meshes  to  finite  element  calculations. 


In  the  following  figures  some  of  the  above  mentiofied  functions  or 
applications  are  briefly  outlined  in  a  simple,  pictorial  form  which 
hopefully  is  self-explanatory,  see  fig .  8,1  and  succeeding  figures.. 


However,  as  regards  AUTONEST,  AUTOPART  and  AUTODRAW,  more  details 
are  given  below. 
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AUTOKON  76 


Fig.  6.  Communications  "between  AUTOKON-76  and 

certain  applications  in  Ineractive  AUTOKON 


Fig.  7*  AUTOKON-7 6  linked  to  interactive  AUTOKON  applications 
from  ongoing  developments 


AUTOKON-76 


U.3  AUTONEST 


This  application  is  briefly  described  in  the  attached  brochure. 
AUTONEST  has  been  in  operation  for  more  than  one  year  in  Aker  and 
in  Verolme  Bozenburg  yard  in  Holland.  We  beleive  it  passed  the 
acid  test-  at  Verolme  and  we  quote  from  the  paper  given  at  the 
AUC-78  meeting  (they  are  using  2  screens  simultaneously) : 

"Figures  about  savings  in  time-  and  money,  comparing 
batch  and  interactive  versions ?  are  very  difficult  to 
caluculate.  VDSM  traditionally  pays  very  much  attention 
to  nested  formats;  Cutting  combination,  use  of  more  torches, 
heat  distortion  and  edge  preparation  does  influence  the  ~:rae 
.needed  for  the  nesting  procedure;  it's  our  yard-policy,  vhich 
has  to  be  followed,*  Performing  this  sometimes  elaborative 
way  of  nesting  interactively  did "show  a  substantional  reduc¬ 
tion  of  manhours  and  calendertime,  even  in  spite  of  all  "he 
problems  which  have  been  mentioned. 

Roughly,  using.  1  -  2  manhours,  in  2-3  days  for  a  plate 
filled  with  U  -  12  parts  in  batch,  now  interactively  3  -  5 
plates  of  this  kind  can  be  done  in  about  1  hour.  (Max. 
performance  12  formats  in  1  hour) . 

Additionally,  one  format  filled  with  67  parts,  some  of  these 
with  inner  contour,  did  take  slightly  more  than  half  a  day, 
against  2-3  days  in  the  old  way." 

AUTONEST  operational  on  a  NORD  3,0/S  computer  with  a  minimum  core 
requirement  of  6k  K  words  (l 6  bits). 


AUTOPART 


t 


As  already  mentioned,  AUTOPART  is  a  subset  of  AUTOMODL,  with  the 
following  features  included. 

Basic  part  coding: 

o  Basic  geometrical  definition  (SL,  CIR,  etc.) 

o  Defining  and  referring  to  predefined  contours 

o  Treating  standards  (cutout,  holes,  etc.) 

Advanced  part  coding: 

o  Split  eontours- 

o  Editing  contours 

o  Generate  and  refer  to  parallel  contours 

o  Divide  surface’  units  (parts) 
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Model  "building 


o  Definition  of  design  and  production  units. 

In  fact  AUTOPART  may  be  considered  also  as  a  stand  alone  part 
coding  system  just 'as  ALKON  basic. 


h .  5  AUTODRAW  .  *  ' 

The  purpose  of  AUTODRAW  is  to  provide  to  following  facilities, 

a.  Verification  of:  - 


o 

*  i 

Contours 

o 

Tables 

o 

Text 

b.  Generation  of  drawings : 

o  '  "Composition”-lay-out 
o  Completion  of  drawings  with 

Text 

Symbols 

Dimension  lines 

:  Identifications/references 

Applying  drawing  "standards" 

o  ^  Generate  other  veiws 

Orthogonal  * 

Perspective  .  . 

Axionometric 

Isometric 

Removal  of  hidden  lines 

c .  Build  and  administrate  the  documentation  file : 


The  subset  of  AUTODRAW  will  include  a),  parts  og  b)  and  c)  as 
far  as  shopdrawings  are  concerned. 
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.  GRAPHICAL  PRESENTATION  OF 
THE  PRODUCT  MODEL 
.  2D  OR  3D  VIEWS 

.  COMPOSITION  AND  EDITING  OF 
DRAWINGS 

.  FULL  COORDINATION  OF  DRAW¬ 
INGS.'  AND  THE  PRODUCT  MODEL 

.  STANDARDIZATION  OF  DRAFTING 
TECHNIQUES 

.  DOCUMENT  ARCHIVE 
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CRT 


.  LINK  TO  WELDING  CONTROL 
PROGRAMS':-.  . 


SPECIFICATION  OF  CONTROL 
DOCUMENTATION  OF  CONTROL 


TABLET 


GRAPHICAL  VERIFICATION 
OF  COMPLETED  PRODUCT  "  I. 
MODEL 

OUTPUT  GENERATION  OF 
SMALL  STEEL  STRUCTURE 
COMPONENTS!  STIFFENERS 
COLLAR  PLATED  ETC, 


GENERATION  OF  MATERIAL 
INTAKE  LISTS 


PIECE  LISTS  AND  L: I 
CUTTING  PLAN  ' 


■  U 


Fig.  13 


16,  17,  V* 
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TABLET 


PRINTER 


STIFNESS  DATA 
MODEL  CHECK 
LOADS  BOUNDARY 
COND. 


NC 

CONTROL, 


PLOTTER 


/BENDING 
/  MOMENT 
SHEAR  FORCE’S 


EXISTING 
PROGRAMS 
E.G.  RULE 
DEPENDENT 
PROGRAMS 


.  PRELIMINARY  STRUCTURAL 
ANALYSIS  THROUGH  BEAM  TEORY 
■  PROGRAMS 

.  FINITE  ELEMENT  METHOD  FOR 
DETAILED  AND  COMPLEX  STRUC¬ 
TURES 

.  GENERATION  OF  DATA  FOR  THE 
MODEL  OF  THE  PRODUCT 


5. 


DEVELOPMENT  SCHEDULE 


AUTONEST  is  operational  and  available. 


The  other  applications  (subsets)  shown  in 


AUTOPART 

AUTODRAW ( S )  ’ 

AUTOMATO  : 

,  AUTOCONT(S) 

are  scheduled  for  completion  in  a  N0RD-10/S  yersion  within  medio 
1979  and  expected  to  be  available,  .for  release  utlimo  1979* 

The  remaining  functions  are  partly  developed  in  parallel  to  the 
extent  needed  for  coordination,  but  are  treated  in  the  following 
order  of  priority: 

AUTOMODL 

AUTODRAW  (enhanced  version) 

AUTOSPEC 

AUTOCONT  (enhanced  version) 

AUTOPREL 

AUTOFEMI 

AUTOPROD 

AUTOPLAN 

The  entire  development  program  is  scheduled  to  be  completed  in 

1982. 


fig.  6. 


1 

i 

\ 

I 
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PRESENT  SIAG-DEVELOPMENTS 


PART  3 

A  U  T  0  F  I  T 


Presented  by 
P.F.  Sorensen,  SRS 


1. 


INTRODUCTION 


AUTOFIT  is  an  abbreviation  for  automated  outfitting, 

AUTOFIT  is  a  computer  based  technical  information  for  piping  design 
and  production  engineering.  The  system  includes  all  main  functions 
such  as  design ,  lay-out,  work  preparation  and  material  take  off. 
AUTOFIT  provides  a  ’‘product  model"  which  is  instrumental  as  a  source 
of  information  to  other-tasks  or  functions:  analyses,  planning, 
shop  automation  and  not  to  forget  other  engineering  functions. 

AUTOFIT  as  a  system  concept  is  common  for  all  outfitting  problems  of 
similar  nature,  such  as  piping,  wiring  and  ducting,  even  if  implemen¬ 
ted  only  for  piping  and  instrumentation. 

AUTOFIT  is  basically  independent  of  product  which  makes  it  equally 
applicable  to  any  piping  system  irrespective  of  purpose:  ships, 
offshore  vessels,  petrochemical  and  chemical  plants,  whether  off-shore 
or  on-shore.  ‘ 

Communications  between  the  user  and  the  AUTOFIT  information  system  is 
based  on  extensive  use  of  interactive  graphics  techniques. 


i 
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OUTLINE  OF  AUTOFIT 


Fig.  A1  shows  the  major  tasks  involved  in  the  total  process  of  piping 

1  *  __  3  _  _X_  u  m  -T  a  *1  v\  m  w.  «  4*  «  T  *4*  rslr  rv  __ 


design  and  production  engineering,  including  material  take-off 


Done  in  the  conventional  way,  these  tasks  may  be  divided  into  three 
rather  logical  phases: 

) 

o  functional  design,  resulting  in  a  P  &  I  diagram  with  all 

associated  information  ip  the  form  of  drawings,  lists  etc. 

o  lay-out  design,  using  either  orthogonal  arrangement  drawings  or 

building  a  sijiall  scale  physical  model,  both  visulizing  the  final 
arrangement .  " 

Both  phases  involves  a  variety  of  calculations  and  analyses. 

o  preparation  of  work  shop  documentation,  such  as  isometrics, 

price  drawings,  material  lists,  etc. 


In  parallel  ; with. these  tasks,  the  designer  has  to  do  material  take-off. 


The  figure  indicates  which  tasks  of  conventional  process  are  included 
in  the  computerization.  It  appears  that  design  of  flow  diagrams  or 
systems  schematics  is  assumed  to  be  done  manually. 


Fig.  A2  Ishows  a  general  view  of  AUTOFIT,  divided  into  main  functions  or 


sub  systems,  which  correspond  very  closely  to  the  sub-division  of  work 
just  described. 


DIAGRAM 
LAYOUT 
ISOMET 
MTO  ' 
CALCUL 


covering  functional  design 
covering  layout  design 
for  workshop  documentation 
for  material  take-off 
.*  covering  analyses  and  calculations 


A  brief  description  of  each  subsystem  is  given  below  together  with  the 
status . 
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2.1 


DIAGRAM 


Covers  the  process  up  to  and  include  complete  P  +  I  diagrams. 

Besides  offering  interactive  drawing  facilities,  DIAGRAM  is  used 
to  establish  the  flow- structure’  (topology)  of  the  various  piping 
systems  and  their  instrumentation  in  the  data  base.  Furthermore- 
the  database  will  contain  pipe  specification,  standards  and  norms, 
component  and  instrument  data.  The  DIAGRAM  database  provides  input 
data  to  MTO  for  initial  material  summaries  for  purchasing  and  to 
LAYOUT  for  physical  layout  and  routing  and  to  OALCUL  for  various 
calculations . 

x 

The  interactive  schema  drawing  facilities  are  operational  on  N0RD-10 
using  Tektronix  ^01^/1.  The  screen  menue  is  operated  by  the  cross¬ 
hair.  Drawings  may  be  hard  copied  or  directed  to  the  plotter  when 
final  drawings  are  desired. 

The  remainder  functions  of  DIAGRAM  now  under  implementation  are 
mostly  interactive,  but  some  intended  for  bulk  input  will  use  card 
reader  as  alterantive. '  However,  totally,  DIAGRAM  will  be  operated 
on  N0RD-10.  Since  N0RD-10  is  used  also  as  RJE  terminal,  card  reader, 
line  printer  and  paper  tape  punch  are  available. 

DIAGRAM  is  scheduled  for  completion  within  1979* 


x  Norwegian  mini  computer  produced  by  Norsk  Data,  Oslo. 
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2.2 


LAYOUT 


Covers  the  continued  process  for  providing  complete  piping  systems 
arrangement  with  the  corresponding  numerical  "model"  in  the  data  base. 
LAYOUT  offers  interactive  facilities  for .definition  of  surroundings 
and  constraints 3  volumes,  of  components  and  restricted  areas,  for  simple 
or  automated  routing  and. interference  control  and  powerful  facilities 
for  visualization  and  drawing.  LAYOUT  cpntains  facilities  for  automatic 
selection  of .  fittings  according  to. standards  and  norms. 

The  LAYOUT  database  provides  input  to  MTO  for  updated  material  summaries 
for  purchasing,  to  ISOMET  for  generating  work  .shop  information  and  to 
CALCUL  for  various  calculations. 

This  subsystem  is  specified  and  designed.  An  "experimental"  version 
will  be  ready  in  August  1978,  the  purpose  of  which  is  to  gain  experience 
with  interactive,  graphips  in  component  and  lay-out  definition  and  simple 
routing. 

A  first  version  of  LAYOUT  is  scheduled  for  completion  first  half  of  1980, 
and  an  enhanced  version  with  numerical  interference  control  and  automated 
routing  primo  1981.  -  ,,  , 

Since  this  subsystem  is  characterized  by  a  very  high  degree  of  inter¬ 
activity,  it  will  be  implemented  on  N0RD-10.  Tektronix  U014/1  will  be 
used,  but  it  is  planned  to  use  refresh  screen  as  well. 


n 

i 

aarnrnm 

1 

I 

n 

1 

1 

ll 

1 

■  ■ 

1! 

1 

n 

II 

■ 

n 

1 

1 

y 

1 

■ 

MB1S 

1 

■ 

■ 

1? 


7* 


DIAGRAM 

LAYOUT 

CALCUL 

■ISOMET 

MTO 

FUNCTIONAL 

ARRANGEM. 

CALCULATION 

GENERATION; 

MATERIAL 

DE5I6N  OF 

OF  PIPING 

AND  - 

OF  INFORM. 

TAKE'OFF 

PIPING 

SYSTEMS 

ANALYSES 

FOR  PREFAB 

and  mater. 

SYSTEMS 

AND 

DEMAND5 

ASSEMBLY 

ADMINISTR. 

1  /l)A“A  FoR  / 
[STANbARt*/ 

\pipiN6Spe<i\ 


A 


^STR.dCTORE 


h\UME*nCAU  I 
Mot£U 


HUTU  FIT 
CONCEPT 

\  GENERAL  VIEW 


130 


2.3  ISOMET 


Covers  the  continued  process  of  breaking  down  the  arrangement  in  assemblies 
and  pieces  for  pre fabric at ion  arid  automatic  generation  of  the  necessary  drawings 
and  other  work  shop  informaton,  including  N/C  bending  tapes.  If  necessary,  the 
drawings  may  be  edited  and  manipulated  interactively. 

The  ISOMET  database  provides  input  to  MTO-for  final  material  summaries  for  pur¬ 
chasing.  Since  the  ISOMET  database  contains  full  description  of  pipe  elements, 
this  information  may  be  utilized'  also  for  various  shop  automation  purposes. 

The  present  version  of  this  subsystem  is  a  stand  alone  version  operated  partly 
on  Uni vac,  partly  on  N0RD-10.  By  nature  ISOMET  is  a  typical  "output"  system 
with  the  purpose  to  convert,  manipulate  and  present  data  base  information  in  a 
rather  repetitive  and  standarized  way  (isometrics,  pipesketches ,  lists).  The 
need  for  interactivity  is  less  than  in  DIAGRAM  and  LAYOUT,  and  ISOMET  is  there¬ 
fore  characterized  by  a  very  high  degree  of  automatic  output.  The  ISOMET  input 
programs  are  temporary  and  intended  for  bulk  input  lifted  from  a  model  or  a 
conventional  arrangment  drawing.  The  input  as  well  as  the  output  programs  pro¬ 
viding  automated  output  and  therefore  operated  on  Univac,  while  interactive 
editing  of  this  output  is  performed  locally  on  N0RD-10. 

When  the  databases  from  DIAGRAM  and  LAYOUT  are  available  on  N0RD-10,  the  ISOMET 
subsystem  will  naturally  be  residing  on  the  same  computer. 
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MTO 

MTO  extracts  information  from  the  "product”  database  and  generate  . 
material  demand  summaries  corresponding  to  the  current  engineering 
status.  MTO  provides  material  requisitions  automatically  and  may 
also  give  material  summaries  sorted  on  different  criterias  such  as : 
line  no.,  area  .(block)  no.,  group, no.,  (for, cost  summary),  activity 
no.  (for  planning) ,  on  materials  code  (for  bulk  ordering),  contract 
type  (for  billing  of  extras),  type  of  work  (prefabrication  or  assembly), 
etc.  MTO  is  command  oriented  and  is  presently  operated  in  batch. 

MTO  'provides  information  to  the  material  administration  system  for 
order  follow-up  and  warehousing.  The  purchase  order  no.  is'  fed  intd 
MTO,  which  is  capable  of  giving  a  complete  status  or  requisitions  and 
orders  versus  demands. 

MTO,  is  operational  on  Univac  1100  as  a  stand  alone  system  with  output 
as  described,  however,  partly  with  provisional  input  programs,  awaiting 
the  availability  fo  the  final  product  data  base  from  DIAGRAM,  LAYOUT 
and  ISOMET.  By  .then,  MTO  will  become  a  typical  output  system.  1 

The  necessary  links  are  designed  and  are  scheduled  for  implementation 
concurrently  with  the  completion  of  the  previous  subsystems'.  The 
intention  is  also  to  implement  it  on  N0RD-10  for  operation  in  conver¬ 
sational  mode. 
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2.5 


CALCUL 


The  flow-structure  (topology)  description  and  function  data  from  the 
DIAGRAM  data  base  and  the  3-dimensional  numerical  model  from  the 
LAYOUT  database  serve  as  reference  for  various  calculations  which  are 
performed  in  the  respective  phases.  Such  calculations  may  comprise 
mass  balance,  pressure  drop,  structural  strength,  analyses,  etc.  The 
extent  and  type  of  calculations  will  depend  on  type  of  piping  system, 
industry,  rules  and  regulations  and  other  user  dependent  demands. 

Therefore,  CALCUL  is  more  an  opening  to  each  user  of  AUTOFIT  to  rewrite 
present  programs  or  develop  his  own  new  programs  in  interface  with  the 
AUTOFIT  data  base,  rather  than  an  off-the-shelf  library  provided  as 
standard  AUTOFIT  routines. 

Calculation  and  analysis  programs  are  usually  batch  or  in  some  cases 
operated  in  dialogue  mode.  , Possibly  except  for  structural  calculations 
by  advanced  FEM  systems  available  on  large  main  frame,  it  is  assumed 
that  most  calculation  programs  may  be  accommodated  on  the  same  computer 
as  AUTOFIT. 

There  are  no  specific  plans  to  develop  calculation  programs  as  off 
the  shelf  packages  as  part  of  AUTOFIT. 
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3. 


HARDWARE 


Great  efforts  are' made  to  develop  AUTOFIT  as  a  portable  and  self- 
contained  software  with  the  highest  possible  degree  of  hardware 
independence.  - 

Nevertheless,  certain  hardware  have  been  selected  during  development, 
mostly  because  of  availability  and  partly  because  of  choice  for  *  ■ 
several  concurrent  developments. 

The  hardware  being  used- coftipbise  general  purpose,  equipment  such  as: 
o  Univac  1110  as  central  main  frame. 

o  Nord-10  as  local  machine  for'  interactive  graphics,'  for  RJE 

terminal  connection- to  Univac  and  for  plotter  control. 

o  Tektronix  UOlU/1  with  EGM  option,  tablet  and  hard  copy  unit. 

The  operational  mode  of  the  various  subsystems  are  already  described. 
However,  it  does  not  necessarily  represent  the  final  solution  when 
AUTOFIT  is  completed. 

Since  AUTOFIT  is  basically  portable,  the  user  is  given  a  certain  amount 
of  freedom  to  pick  hardware  such" as  computer,  screen  and  plotter. 

As  appearant  today,  a  minimum  computer  requirement  for  accommodation,  of 
AUTOFIT  will  be  192  K  words,  2  discs  drives,  1  tape  station,  card  reader, 
line  printer,  paper,  tape  punch.  The  final  configuration  in  terms  of 
capacity  cannot  be  specified  in  detail  now,  simply  because  the  system  is 
not  yet  completed. 

Other  capacity  demands  such  as  number  of  work  stations  (screens)  are 
set  by  the  user  environment.:  volume  of  work  to  be  performed,  the  geo¬ 
graphical  distribution  of  work  and  whether' the  same  hardware  and  work 
stations  are  intended  also  for  other  applications.  The  core  requirements 
on  Nord-10  will  increase  .with  the  number  of  work  stations  in  a  multi  -user 
mode  operation.  *  '  • . 

It  is  technically  feasible  to  operate  AUTOFIT  on  Univac  1100.  The  ’ 
efficiency  is,  however,  entirely. dependant  on  the  computer'  center  opera¬ 
tion  policy  and  work  load.  ; 
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PRESENT  SIAG-DEVELOPMENTS 

PART  h 


Hardware  Considerations  in  the 
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Introduction 
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This  part  of  the  AUTOKON/AUTOFIT  will  deal  with  the  following  aspects 

o  Trends  in  Hardware  development 
o  AUTOKON/AUTOFIT  hardware  considerations 
o  Graphics  hardware  development 

o  How  does  the  '’turnkey"  systems  fit  into  the  total  AUTOKON/ 
AUTOFIT  system 

o  SRS  -  SIAG  development  policies 


1.  What  types  of  systems  are  AUTOKON  and  AUTOFIT  ? 

i 


Let  us  review  two  important  points 
a  Information  Systems 

This  means:  They  are  to  be  considered  a  central  information 
source  from  which  the  different  application  programs 
(which  belongs  to  AUTOKON/AUTOFIT)  fetches  and  stores  data. 

b  Topological  product  model 

The  key  to  this  information  is  a  product  model  which  is  a 
logical  description  of  how  the  different  parts  and  prices 
of  the  product  are  tied  together. 

To  administer  this  information  consisting  of  topology  and  geometry 
requires  a  powerful  and  resource  demanding  Database  system.  The 
storage  requirements  are  also  great . 

> 

In  addition  several  applications* with  several  users  each* may  wish 
to  access  this  informations  simultaneously. 


! 
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Finally  most  of  the  applications  wish  to.  utilize  interactive  Com¬ 
puter  graphics  as  a  means  of  communication  between  the  user  and 
the  information  system. 

In  order  to  evaluate  the  possible  hardware  configurations  for  these 
resource  demanding  systems  it  is  necessary  to  take  a  look  at  hard¬ 
ware  development  trends  in  general. 


Hardware  trends 


The  hardware  development  trends  for  todays  MINI/MIDI  computer  can  be 
explained  by  the  following  points 


o  The  introduction  of  LSI  (Large  Scale  Integration)  technology 
is  bringing  the  price  and  size  down  on  basic  components. 

( CPU ' s ,  memory  etc . ) 

o  Due  to  this  fact  there  is  a  tendency  to  move  in  the  direction 
of  32  bit  hardware  (instead  of  1 6  bit). 

o  MICRO  computers  will  be  used  as  logical  components  for 
functions  such  as 

-  driving  plotters  aqd  digitizers 

-  interfaces  towards  equipment 

-  etc.,  etc. 

o  MULTI  -  CPU  architectures  where  a  particular  CPU  may  be 
assigned  one  particular  function  or  task 

ex.  -  Database  function 

-  display  handling 

M  * 

o  Distributed  processing  utilizing  several  computers  connected 
together.  This  hds  a  positive  influence  on  the  following 
factors 


-  Expandability 

-  Total  system  downtime 

-  Graphics  devices  may  be  connected  through  short 
high  speed  lines 

-  etc . 


Example  of  the  last  two  points  are  shown  on 


fig.  1 


and 


137 


TERMINALS 


MINI  COMPUTER  HARDWARE  ARCHITECTURE 
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Fig. 2  FUTURE  "MINI 
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AUTOKON/AUTOFIT  estimated  performance 


We  have  tried  to  estimate  resource  demands  based  on  equipment  -we 
already  know. 

The  machine  configuration  for  the  estimate  is  a  NORD  10/S  1 6  bit  mini 
computer  with 

o  192  -  256  K  16  bit  Word  memory 
o  5  “  6  terminals  (of  these  3  tektronix  liOl^O 
o  Mass  storage  66  -  l60" Megabytes 
o  Magnetic  tape  station 
o  On  "line  plotter 

The  following-  performance  was  "estimated" . 

LOAD: 


3  -  5  users  simultaneously 

-  on  same  or  different  sub-systems 

-  on  same  or  different  database 

-  sporadic  communication  with  systems  on  other  machines 


RESPONSE  TIMES: 


-  Graphical  interaction  2-5  sec . 

-  Updating  database  1-30  sec . 
switching  application  1  -  5  min 

-  changing  (redefining) 

product  model  1-6  hours 

It  should  be  noted  that  data  given  for  storing  on  the  database  covers 
aspects  from  storing  of  simple  geometry  to  complex  topological 
structures . 
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Graphics  Hardware  development 


Just  like  for  the  MINX  computer  the  LSI  technology  will  make  a  huge 
impact  on  the  Graphics  hardware 

A  typical  Graphics  System  will  contain  one  or  more  microcomputer  : 
performing  different  functions  such  as 

Picture  processor  for  Refresh  System.  This  indicates  that 
refresh  systems  will  be  more  attractive( maybe  in  connection 
with  storage  capabilities) 

Communication  processor  to  host  computer 

Basic  Graphics  functions  such  as 

-  2D/3D  transformations 

-  Window/ viewpor ting 

-  "Hidden  line"  removed 


On  the  whole  this  indicates  cheap  workstations  capable  of  acting 
as  stand  alone  systems  for  certain  input/output  function,  f.  inst. 
digitizing,  drawing  editing  etc.  in  much  the  same  way  as  the  Turnkey 
systems  of  today  only  at  a  much  lower  price. 

However,  we  see  these  work  stations  only  as  graphic  input/output 
devices  for  the  total  information  system  capable  of  doing  some  stand 
alone  functions „ not  as  a  medium  for  implementing  the  total  system. 

This  would  only  serve  to  concentrate  the  processing  problems  as  the 
work  station  instead  of  distributing  the  processing  between  the 
workstation  and  the  total  information  system. 


How  do  we  prepare  for  known  and  unknown  turnkey  systems  ? 


The  introduction  of  graphical  turnkey  systems  or  work  stations  allows 
us  to  reduce  the  processing  load  on  the  host  computer(s). 

However,  they  do  introduce  the  problem  of  defining  "software  inter¬ 
section"  between  the  host  computer(s)  and  the  workstation  since  no 
two  turnkey  systems  look  alike 

o  they  supply  different  functions 

o  they  represent  data  differently  (f.inst.  geometry) 


In  order  to  reduce  the  amount  of  -work  involved  in  integrating  a 
turnkey  system  the  following  aspects  have  been  given  attention 

o  To  separate  the  Topology  and  Geometry  description  of  the 
product .  While  many  turnkey  systems  handle  geometry 
adequately  they  do  now  handle  your  particular  products 
topology 

o  To  separate  functions  that 

-  manipulate  topology 

~  manipulate  geometry 

o  To  separate  functions  that  manipulates  graphics  data 

-  Display  code  generation 

-  Display  code  manipulation 

-  2D  &  3D  transformation 

-  etc. 


o  To  base  the  development  on  identical  software  packages  or 
building  blocks  to  reduce  overal  maintenance  and  adjust¬ 
ment  to  new  turnkey  systems 

-  Database/file  systems 

-  Command  processor 

-  Graphics  software 

-  Geometry  routines 
~  -  Text  manipulations 

-  Documentations 

-  etc . 

Development  policy 


We  would  like  to  finish  by  summing  up  our  development  policies 
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PORTABILITY 


We  do  want  to  make  portable  systems .  This  means  independance 
of  hardware,  both  computer  and  turnkey /workstation ,  although 
this  does  not  allow  us  to  optimize  on  a  giv^u  configuration 
initially.  It  allows  us  to  adjust  to  new  hardware  that  comes 
along  (or  hardware  already  in  a  yard) . 


SOFTWARE  STANDARDIZATION 


We  are  attempting  to  base. our  development  on  common  software 
packages . 


We  develop  for  1 6  bit  minis  with  an  address  space  of  64  words 
although  we  believe  that  the  32  bit  machines  will  dominate  in 
the  future. 


We  believe  in  MINIS  (or  MIDIS)  for  interactive  work  either 
connected  to  other  MINIS  (MIDIS)  or  to  main  frames . 


We  do  develop  using  Tektronix  4014  but  try  to  accomodate  the 
cheap,  intelligent  work  stations  that  we  believe  are  comming. 
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Additional  copies  of  this  report  can  be  obtained  from  the 
National  Shipbuilding  Research  and  Documentation  Center: 

http://www.nsnet.com/docctr/ 

Documentation  Center 
The  University  of  Michigan 
Transportation  Research  Institute 
Marine  Systems  Division 
2901  Baxter  Road 
Ann  Arbor,  Ml  48109-2150 

Phone:  734-763-2465 

Fax:  734-763-4862 

E-mail:  Doc.Center@umich.edu 


